Combining Static and Dynamic Analyses to Detect Interaction Patterns

We detect interaction patterns in legacy code combining static and dynamic analyses. The analyses do not depend on coding or naming conventions. We classified potential pattern instances according to the evidence our analyses provide. We discuss our approach with the Observer Pattern as an example. Our Java implementation analyzes Java programs. We evaluated our approach by self applying the tool looking for Observers in its code. In general, our tool detects all Observer Pattern instances actually contained in the code as candidates, i. e., we do not miss a single pattern instance. In the example, the candidates our tool considers Observers with high evidence include 80% of the actual Observer Pattern instances and no false positives. INTRODUCTION The tasks of component development and systems integration are often performed by staff located in different organizations. Additionally, the process of component development cannot in general be aware of all the system integration requirements. Hence, mismatches between components are the rule, not the exception, making adaptation an integral part of component-based systems design. This almost always affects the interaction of components and thus the system architecture (Heuzeroth et al., 2001). In existing legacy systems, we often have to identify components, first. To perform the necessary changes, programmers further need to understand the system architecture and behavior. Since the system architecture is almost always scarcely documented or even not available, discovering or recovering design information from existing systems is crucial for understanding and refactoring these systems. Therefore, tools to automatically extract design and architectural information are required. We propose to retrieve static as well as dynamic information. Both are then combined to obtain the desired information on the pattern to be detected. There are situations, where neither static nor dynamic analyses alone are sufficient (or not with acceptable expenses). E. g., it is not statically computable, which method or attribute is actually called or accessed at run time and how often. Even data flow analyses cannot predict all branches and loops, especially when the program to be analyzed requires user interactions. As objects are created at run time, relations among objects are dynamic by nature. The idea is to distinguish a static and a dynamic pattern. The former restricts the code structure the latter the runtime behavior. Analyzing with the static pattern results in a set of candidate instances in the code. In practice this set is large and programmers hardly want to screen all of them to detect the actual instances. Therefore, we test executions of the instance candidates found by the static analysis wrt. the dynamic pattern. The results of dynamic analyses depend on an execution of the candidate instances. Methods not executed at run time cannot be evaluated wrt. the dynamic pattern thus providing no information. However, testing techniques and environments guarantee that each reachable program part is executed while testing (of cause not every program sequence). Using these techniques, we may consider dynamic information available for each candidate instance. Moreover, we argue that parts that are less frequently executed are also less critical for understanding and for restructuring. Our approach requires the source code to be available, and the programs to be executable to observe their dynamic interaction aspects. We explicitly excluded all dependencies to coding and naming conventions. Hence, our approach also detects interaction patterns occurring by chance. In the remainder of the document, we consider the Observer Pattern (Gamma et al., 1995) (event notification) as a special architectural pattern. It is frequently used in frameworks and applications to realize loose coupling of objects or components. Suppose the following scenario: we tailor the framework or application for an environment requiring efficient communication among statically known partners. In such a setting, the Observer Pattern would be inappropriate. Thus, we need to detect it and replace it by a more efficient solution. We need static and dynamic analyses to detect the Observer Pattern. The static analysis computes a set of classes that fulfill the necessary properties for subject and corresponding listener classes. The dynamic analysis then monitors objects of these classes during execution and checks whether the interaction among them satisfies the dynamic Observer protocol. We present our approach comprising the static and dynamic analyses in Section APPROACH. This section also discusses implementation details. In Section EVALUATION we evaluate the results of applying our analyses to the code of our tool. Section RELATED WORK discusses related work. Finally, we conclude and show directions of future work in Section CONCLUSIONS AND FUTURE WORK. APPROACH In this section we present our approach to detect interaction patterns by combining static and dynamic analyses. Section COMPONENT MODEL introduces our component model to show the goal of the analyses. Section STATIC ANALYSIS discusses the static analysis, Section DYNAMIC ANALYSIS the dynamic analysis. Section TOOL DESIGN sketches the design of our tool performing static and dynamic analyses. COMPONENT MODEL For the purpose of this paper, we define components to be software artifacts with typed input and output ports. This definition focuses on computational components, but is sufficiently general to cover all other variants. Input ports are connected to output ports via communication channels called connectors. The notion of ports and connectors are known from architecture systems (Shaw and Graham, 1996, Bass et al., 1998). Some connectors may be as complex as most components, and thus require the same amount of consideration in design, but they all base on simple synchronous or asynchronous point-to-point data paths. Figure 1 sketches this basic component model. In general, ports and connectors are implemented by patterns using basic communication constructs like calls, RPCs, RMIs, input output routines etc. provided by the implementation language or the component system. The Observer Pattern is such a port and connector implementation as it connects an event generator with some listener objects. The notification generally involves calling an event handling method of the listeners, where the subject waits for every call to return. Although, the pattern can be considered as asynchronous communication, since the events may occur arbitrarily, the notification itself constitutes a synchronous action. In contrast to such an implementation, the ports and connectors themselves abstract from details. A port defines points in a component that provide data to its environment and require data from its environment, respectively. A connector defines out-port and in-port to be connected and specifies whether data is transported synchronously or asynchronously. In order to extract components from a system and adapt them to a new environment, we prefer a view on the system containing abstract ports and connectors. However, legacy (source) code only contains port and connector implementations scattered throughout the code. The goal of our analyses is to compute the abstract port and connector view on these systems. Implementations of ports and connectors follow communication design patterns. In order to retrieve an abstract view, we search for the patterns. The static analysis computes potential program parts playing a certain role in a communication pattern. The dynamic analysis further examines those candidates. We can thus consider static and dynamic analyses as filters that narrow the set of candidates in two steps. Figure 2 illustrates our approach. In the subsequent subsections, we use the Observer Pattern as a running example. The following naming conventions refer to roles of certain methods of the Observer Pattern. Figure 3 sketches an implementation. Note that this naming convention is only used for explanations in this paper; the static analysis does not refer to those name. : a method responsible for adding listener objects to a subject object. : a method responsible for removing listener objects from a subject object. "! : a method responsible for notifying the listeners of a state change in the subject. # $ : a method implemented by the listener objects, called by the "! method. We assume that , % & as well as "! are contained in a single class and are not distributed among different hierarchies. This is not an unnatural restriction, but reflects object-oriented design principles. STATIC ANALYSIS The program source code is the basis for the static analysis; it is represented by an attributed abstract syntax tree (AST) as computed by common compilers. A static pattern is a relation over AST node objects. It is defined by a predicate ' using the information in the attributed AST as axioms. Names of variables, methods and classes nodes may be compared with each other but not with constants, thus making the pattern definitions independent on naming conventions. The static analysis reads the sources of the program in question and constructs an attributed AST. Then, it computes the pattern ' relation on the AST nodes and provides the result as a set of ( , i. e., pattern instances with the appropriate static structure. This set is a conservative approximation to the actual patterns in the code. The dynamic analysis, cf. Section DYNAMIC ANALYSIS, refines this approximation later on.